I'd be happy to add the backwards-compatible Thin trait, but I'd prefer not to update from_raw_parts yet. I don't think it provides a significant enough ergonomics or functionality improvement to justify the semver breakage. I consider this the "stable" part of "radioactive stabilization".

Many of the choices around these APIs have not yet been thoroughly debated because the ptr_meta RFC is still unstable. Despite this crate being (approximately) a stabilization of the ptr_meta RFC, it already deviates from it in a few places. For example, there's no way to provide builtin methods on pointers and NonNull. A previous version of ptr_meta provided extension traits to almost get there, but in the end it triggered too many clippy lints and was generally a bad experience. Hopefully this helps explain my position a little bit better.

I think that if we get a good reason to release a new breaking version of this crate in the future, we should seize the opportunity and also update from_raw_parts to accept *mut impl Thin.

Totally understand. We just stumbled on this crate while trying to get rid of all our nightly features and I noticed the slight difference and thought I'd quickly toss this PR up. And yep like you said the difference is so small that it isn't worth the breaking change if you aren't trying to keep this 1:1. Closing for now :)